Identifying routes between an origin and a destination is an important part of routing a package or seating a passenger. One system for identifying routes is shown in FIG. 1A. A system 150 may include an AirCore or other computing system 152 that accesses a routings engine 154. For example, a computing system 152 may generate a request for routes between San Francisco and New York City at a particular time and date. The routings engine 154 searches a listing of flights, such as stored in a database, and returns a response containing a listing of flight paths that match San Francisco and New York City for approximately the particular time and date.
The number of available routes from the origin to the destination can be nearly endless when considering more than only direct routes. For example, a trip from San Francisco to New York City can be flown directly, or can be flow through Chicago, Dallas, Nashville, Seattle, etc. The permutations through possible routes from the origin to the destination, even with modern computing systems, may take several seconds to traverse and generate a list for display to a user. These calculations, particularly during peak times when many users are accessing the computing system to search routes, may cause unpleasant delays for users of the computing system for determining flight routes.
One conventional solution to enhancing the experience of a user searching for routes is to cache certain results. A first query to the routings engine 154 for flights from San Francisco to New York City may take a long period of time, such as several seconds, to execute. The user is then provided the results in a response from the Routings Engine. These results may also be cached in memory. A second query to the routings engine 154 for the same San Francisco to New York City path at the same time and date may return results from the cache, and thus be returned to the user in a response in a much shorter period of time, such as fractions of a second. One conventional application of caching in the routings engine is shown in FIG. 1B.
FIG. 1B is a flow chart illustrating caching of flight routes in a routing engine. A method 100 begins with receiving a route request at block 102 and determining whether the results of the response are present in the cache at block 104. If so, the response is loaded from the cache at block 110, the response framed in a response message at block 112, and the response sent at block 114. If the request is not present in the cache at block 104, then the method 100 processes routes for the request at block 106, stores the request and response into the cache at block 108, frames the response in a message at block 112, and sends the response at block 114.
Caching may improve the response time of repeated, identical requests to the routings engine. Although caching improves the response time in some situations, the first user making a request that is not stored in cache must still wait a relatively long duration of time before receiving a response. This long duration of time creates an unpleasant experience for the user.